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Service-Oriented  Architecture  (SOA)  is  having  a  major  impact  on  the  acquisition  and  development  of  software  systems 
because  of  its  potential for  increased  business  agility,  adaptability  of  applications,  interoperability  between  systems,  and  reuse 
of  legacy  assets.  However,  organisations  often  make  decisions  on  SOA  adoption  without  carefully  analysing  the  implications 
of  their  decisions.  This  article  outlines  a  set  of  common  misconceptions  about  SOA  and  suggests  ways  to  more  effectively 
address  critical  SOA  issues  that  potential  users,  developers,  and  acquisition  officers  may  have. 


You  do  not  have  to  look  far  to  become 
aware  of  the  effect  that  SOA  is  hav¬ 
ing  on  software  systems.  Vendors  are 
aggressively  marketing  hardware,  soft¬ 
ware,  tools,  and  services  that  support  SOA 
implementation  within  organizations  as 
diverse  as  tire  Department  of  Defense 
(DoD),  banks,  federal  agencies,  manufac¬ 
turing  companies,  and  health  care 
providers.  Even  more  significantly,  cus¬ 
tomers  are  embracing  SOA  with  the  goal 
of  reaching  a  previously  unachievable 
level  of  interoperability  among  systems 
and  agility  in  business  practices. 

SOA  may  currently  be  the  best  avail¬ 
able  solution  for  achieving  interoperabili¬ 
ty  and  agility,  as  well  as  providing  a  tech¬ 
nology  upgrade  path  that  preserves  the 
investment  in  legacy  systems  and  simpli¬ 
fies  deployment  of  new  systems. 
However,  our  experience  from  working 
with  customers  considering  the  adoption 
of  SOA  suggests  that  they  often  have  a 
variety  of  misconceptions  that  lead  them 
to  greatly  underestimate  the  effort 
required  to  successfully  implement  SOA. 
These  misconceptions  are  dangerous 
because  they  make  organizations  more 
susceptible  to  vendor  advertising  and 
hype.  In  addition,  these  misconceptions 
are  often  embraced  by  internal  IT  organi¬ 
zations,  leading  them  to  over-promise 
new  capabilities,  while  underestimating 
the  cost  and  effort  required  for  achieving 
even  modest  improvements.  Although 
some  of  these  common  misconceptions 
also  apply  to  traditional  single  systems,  we 
focus  on  their  relevance  to  SOA-based 
systems. 

We  hope  that  by  recognizing  these 
misconceptions,  organizations  can  better 
understand  and  evaluate  the  promises  of 
vendors  and  improve  their  own  internal 
SOA  expectations  and  planning  processes. 

Basic  SOA  Concepts 

SOA  is  a  way  of  designing  systems  com¬ 
posed  of  services  that  are  invoked  in  a  stan¬ 
dard  way.  As  an  architectural  style,  SOA  is 
neither  a  system  architecture  nor  a  com¬ 


plete  system.  An  SOA-based  system  is 
composed  of  die  following: 

•  Services  that  are  reusable  components 
that  represent  business  or  mission 
tasks,  such  as  customer  lookup,  weadi- 
er,  sensor  placement,  account  lookup, 
or  credit  card  validation. 

•  Service  consumers  that  are  clients  for 
die  functionality  provided  by  the  ser¬ 
vices,  such  as  end-user  applications, 
systems,  or  even  other  services. 

•  SOA  infrastructure  diat  connects  ser¬ 
vice  consumers  to  services. 

The  most  common  approach  to  SOA 
implementation  is  diat  of  Web  services, 
which  relies  on  common  standards  that 
include  HTTP,  SOAP,  WSDL,  and  UDDI. 
However,  odier  SOA-based  systems  can 
be  implemented  using  such  technologies 
as  MOM,  IBM  WebSphere  MQ,  publish- 
subscribe  systems  such  as  JMS,  and 
CORBA. 

Some  SOA  Misconceptions 

Seven  common  misconceptions  are  iden¬ 
tified  in  the  following  subsections.  The 
subsection  heading  represents  a  statement 
in  the  form  that  an  organization  might 
express  it.  The  body  of  each  subsection 
discusses  why  the  statement  expressed  in 
die  heading  can  be  misleading.  It  also  pro¬ 
vides  advice  on  how  to  avoid  falling  into 
common  traps. 

SOA  Provides  the  Complete 
Architecture  for  a  System 

Chief  among  SOA  misconceptions  is  the 
belief  diat  simply  by  adopting  an  SOA 
strategy  for  the  enterprise,  an  organization 
has  established  a  complete  well-crafted 
architecture  diat  will  help  the  organization 
achieve  its  IT  goals.  In  reality,  SOA  is  not 
an  architecture,  but  an  architectural  pat¬ 
tern  from  which  a  number  of  specific 
architectures  can  be  derived  -  bodi  good 
and  bad.  An  architectural  pattern  provides 
guidance  to  an  architect  diat  enables  lever¬ 
aging  best  practices  for  that  specific  pat¬ 
tern.  It  defines  a  set  of  element  types,  a 
topological  layout  of  the  elements  that 


shows  their  relationships,  semantic  con¬ 
straints  on  elements,  and  interaction 
mechanisms  [1],  For  example,  the  ele¬ 
ments  in  the  SOA  pattern  include  service 
consumers,  service  descriptions,  service 
implementations,  and  possibly  a  service 
bus.  One  relationship  is  diat  between  ser¬ 
vice  providers  and  service  consumers.  In 
the  case  of  Web  Services,  consumers  and 
services  are  connected  by  HTTP  or 
HTTPS  connectors  carrying  SOAP  mes¬ 
sages.  Given  the  architectural  elements,  or 
building  blocks,  any  number  of  systems 
can  be  developed  based  on  this  architec¬ 
tural  pattern.  These  concrete  elements  and 
their  interactions  are  the  architecture  of 
the  system. 

The  misconception  diat  SOA  provides 
a  complete  architecture  also  leads  cus¬ 
tomers  to  believe  diat  they  can  buy  SOA 
off  the  shelf.  Although  there  are  a  number 
of  products  available  in  die  marketplace 
that  can  help  an  enterprise  implement 
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SOA,  none  of  them  are  actually  an  imple- 
mentation  of  an  SOA-based  system. 
Software  architects  still  need  to  architect 
systems  based  on  the  SOA  architectural 
pattern.  They  have  to  design  services  and 
service  interactions  that  meet  the  quali¬ 
ties  that  stakeholders  expect  of  the  sys¬ 
tem.  In  addition,  the  architect(s)  must 
make  decisions  on  how  services  are 
implemented.  Service  implementations 
may  involve  developing  new  software, 
wrapping  a  legacy  software  system,  incor¬ 
porating  services  provided  by  third  par¬ 
ties,  or  a  combination  of  these  options. 

Information  about  the  quality  attrib¬ 
utes  of  SOA-based  software  systems  is 
just  beginning  to  become  available  in  the 
literature:  One  report  finds  that  SOA 
promotes  modifiability,  interoperability, 
and  extensibility,  but  can  have  a  negative 
impact  on  security,  performance,  testabil¬ 
ity,  and  auditability  [2],  For  a  given  sys¬ 
tem,  the  architect  needs  to  understand 
the  quality  attribute  requirements  and 
needs  to  architect  a  concrete  system 
around  the  tradeoffs  that  are  most 
important  to  the  stakeholders  of  the  sys¬ 
tem. 

All  Legacy  Systems  Can  Be  Easily 
Integrated  Into  an  SOA  Environment 

One  of  the  most  attractive  promises  of 
moving  towards  SOA  is  that  it  enables 
reusing  legacy  systems,  thereby  providing 
a  significant  return  on  the  investment  in 
these  systems.  However,  migrating  legacy 
systems  is  neither  automatic  nor  easy.  It 
might  not  make  business  or  technical 
sense  to  migrate  the  legacy  system  to  an 
SOA  environment. 

It  is  important  to  understand  technical 
constraints  of  the  legacy  components, 
such  as  immature  technology,  that  may 
require  significant  rework.  In  addition,  it  is 
necessary  to  understand  business  issues, 
such  as  the  business  case  that  will  justify 
die  migration  of  legacy  components  to 
services  in  the  specific  context.  An 
upfront  and  hands-on  analysis  of  techni¬ 
cal  feasibility  and  the  resultant  return  on 
investment  will  help  to  avoid  last-minute 
surprises. 

This  analysis  must  answer  at  least  the 
following  questions: 

1 .  Have  consumers  for  the  services  been 
identified? 

2.  Is  it  technically  feasible  to  create  a  ser¬ 
vice  from  the  legacy  system  or  part  of 
die  system? 

3.  How  much  would  it  cost  to  expose 
services  from  the  legacy  system? 

4.  What  changes  will  have  to  be  made  to 
legacy  systems  in  order  to  use  these 
services? 


5.  How  much  will  these  changes  affect 
die  current  end  users  of  the  legacy  sys¬ 
tem  and  odier  dependent  production 
systems? 

6.  Are  die  costs  of  exposing  services, 
together  with  die  associated  risks  of 
making  the  required  changes,  feasible 
from  a  business  perspective? 

The  bottom  line  is  that  there  are  issues 
to  take  into  consideration  that  go  beyond 
adding  a  service  interface  to  an  existing 
system. 

SOA  Is  All  About  Standards  and 
Standards  Are  All  That  Is  Needed 

This  statement  primarily  applies  in  the 
context  of  Web  services,  the  main  stan- 
dards-based  technology  available  today  to 
realize  SOA.  This  leads  to  a  corollary  mis¬ 
conception  that  SOA  and  Web  services 
are  the  same.  In  reality,  Web  services  are 
only  one  potential  approach  to  SOA 
implementation. 

It  is  true  that  public  standards  like 
those  supporting  Web  services  are  often 
preferable  to  proprietary  solutions 
because  they  are  (potentially)  supported 
by  a  wider  community.  But,  most  Web  ser¬ 
vice  standards  are  still  emerging  and  sub¬ 
ject  to  multiple  interpretations. 

Basic  infrastructure  standards  that 
support  the  exchange  of  messages 
between  service  consumer  and  provider- 
such  as  HTTP,  XML,  XML  Schema, 
SOAP,  WSDL,  and  UDDI  are  the  most 
developed  and  mature  of  the  Web  service 
standards.  However,  being  stable  for  years 
does  not  mean  that  die  standards  are  com¬ 
plete.  For  example,  after  adopting  basic 
infrastructure  Web  service  standards, 
some  organizations  found  that  their  ser¬ 
vices  still  could  not  communicate  infor¬ 
mation  effectively  with  other  services  due 
to  different  design  decisions  and  flexibili¬ 
ty  in  die  standards.  The  WS-I  Basic  Profile 
was  constructed  to  provide  better  interop¬ 
erability  across  implementations  using 
basic  infrastructure  standards  [3],  In  addi¬ 
tion,  revisions  to  standards  are  likely  in 
any  area  undergoing  rapid  advances  in 
technology. 

Standards  for  service  composition  (e.g. 
WSCL,  WS-Coordination,  BPEL,  and 
cross-cutting  standards  [e.g.  WS-Security, 
SAML,  WS-Transaction,  WS-Reliability]) 
are  less  mature  and  far  less  stable  than 
basic  infrastructure  standards.  Currently, 
there  are  a  number  of  competing  propos¬ 
als  and  standards  for  service  composition 
and  cross-cutting  concerns  that  conflict 
and  overlap.  Regarding  these  less  mature 
areas  of  Web  services,  die  old  saying  sums 
it  up  -  the  best  thing  about  standards  is  that 
there  are  so  many  to  choose  from. 


SOA  Is  All  About  Technology 

Vendors  pushing  SOA  products  will  (for 
good  reason)  promote  their  technologies 
as  the  solution  to  an  organization’s  IT 
problems.  However,  SOA  also  entails 
changes  to  the  organization’s  IT  gover¬ 
nance  model  —  die  set  of  rules  and  regula¬ 
tions  under  which  an  IT  department  oper¬ 
ates,  and  the  mechanisms  to  ensure  com¬ 
pliance  with  those  rules  and  regulations. 
This  is  especially  true  if  SOA  is  used  to 
support  business  processes  or  mission 
threads.  Therefore,  a  well-defined  gover¬ 
nance  model  that  includes  items  such  as 
the  following  is  essential  for  the  success  of 
SOA  implementation: 

•  Service  identification  that  maps  to 
business  or  mission  goals. 

•  Service  repository  management. 

•  Service  implementation  guidelines. 

•  Change  management  to  deployed  ser¬ 
vices. 

•  Mechanisms,  tools,  and  policies  for 
maintaining  and  monitoring  deployed 
services. 

•  Policy  enforcement  at  design  and  run 
time. 

•  Security  and  access  control. 

•  Definition  and  enforcement  of  SLAs 
between  service  consumers  and 
providers. 

The  implementation  of  SOA  in  an 
organization  should  be  part  of  a  larger 
effort  to  assure  that  SOA  and  related  gov¬ 
ernance  are  aligned  with  strategic  goals 
and  objectives. 

The  Use  of  Standards  Guarantees 
Interoperability  in  an  SOA 
Environment 

True  interoperability  can  only  be  achieved 
if  service  consumers  and  providers  inter¬ 
operate  at  both  the  syntactic  and  semantic 
levels.  There  is  interoperability  at  the  syn¬ 
tactic  level  if  they  can  exchange  raw  data 
elements  such  as  text,  numbers,  or  dates. 
There  is  interoperability  at  the  semantic 
level  if  they  understand  and  agree  on  the 
meaning  of  exchanged  data.  For  example, 
a  spacecraft  monitoring  application  may 
rely  on  a  service  that  does  an  analysis  of 
data  received  from  onboard  sensors.  The 
service  may  correctly  perform  the  analysis 
of  the  raw  temperature  data.  However,  it 
may  make  an  assumption  that  the  temper¬ 
ature  data  is  expressed  in  Celsius  as 
opposed  to  Fahrenheit.  In  such  a  case, 
there  is  interoperability  at  the  syntactic 
level,  but  not  at  the  semantic  level.  In  this 
example,  both  die  requesting  consumer 
and  the  onboard  sensor  share  a  common 
understanding  diat  the  number  exchanged 
represents  temperature.  However,  there 
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must  also  be  a  deeper  understanding  of 
die  meaning  of  that  value,  such  as  the 
temperature  unit  or  where  and  how  it  was 
measured  [4],  The  results  of  an  incorrect 
assumption  in  this  case  could  prove  disas¬ 
trous  for  the  mission. 

In  die  case  of  Web  services,  for  ser¬ 
vice  consumers  and  providers  to  be  inter¬ 
operable  it  is  not  sufficient  to  agree  on  the 
representation  of  data  in  XML  documents 
because  there  is  no  way  to  specify  the 
meaning  of  data  in  an  XML  or  WSDL 
document  odier  than  in  text  descriptions. 
The  problem  is  that  text  descriptions  are 
imprecise,  are  often  not  filled  in,  and  are 
not  readable  by  machines,  rendering  diem 
open  to  multiple  interpretations  by  human 
developers.  Also,  even  diough  the  full 
XML  Schema  Datatypes  specification  can 
be  used  to  specify  data,  it  is  rare  to  see 
anything  other  than  a  data  type  in  the 
WSDL  document  that  describes  Web  ser¬ 
vice  operations.  Optimal  methods  of 
describing  the  meaning  of  Web  service 
inputs  and  outputs  in  a  formal  manner  is 
still  an  area  of  active  research  [5,  6]. 

A  Service  Registry  Allows  Service 
Binding  Dynamically  at  Runtime 

Currendy,  binding  to  services  is  usually 
done  at  design  time.  This  is  referred  to  as 
static  binding  or  fully-grounded  binding. 
Discovery  and  composition  of  services 
are  done  at  design  time  such  that  the 
developer  can  discover  the  syntax  and 
semantics  of  die  service  before  it  is  actu¬ 
ally  used.  In  the  case  of  dynamic  binding, 
discovery  and  composition  of  services  are 
done  at  runtime.  This  is  currently  a  com¬ 
plex  and  poorly  supported  task. 

In  a  basic  scenario  of  dynamic  bind¬ 
ing,  service  consumers  retrieve  the  service 
address  from  a  registry  before  each  call  to 
die  service.  If  diere  are  several  providers 
of  the  same  service,  the  service  consumer 
can  choose  at  runtime  which  one  to  use. 
The  consumer  can  also  rank  providers 
based  on  quality  of  service  criteria, 
choose  a  preferred  provider,  and  use  oth¬ 
ers  as  backup  if  the  preferred  service  is 
not  available. 

More  advanced  automatic  discovery 
and  composition  of  new  services  at  run¬ 
time  requires  the  use  of  common  ontolo¬ 
gies  by  service  providers  and  consumers 
within  a  domain  to  describe  function  and 
usage  of  services.  Given  this  shared  ontol¬ 
ogy,  it  would  still  be  necessary  to  develop 
components  diat  can  construct  die  right 
queries  for  the  discovery  of  services,  com¬ 
pose  services  when  there  is  not  a  single 
service  that  provides  the  needed  function, 
and  dien  provide  the  right  data  to  invoke 
die  discovered  service.  Current  technolo¬ 


gies  have  not  advanced  to  a  point  where 
diis  is  possible  in  production  environ¬ 
ments  [7], 

Testing  SOA-Based  Systems  Is  No 
Different  Than  Testing  Any  Other 
Type  of  System 

Testing  service  consumers,  as  well  as  the 
services  themselves,  is  challenging  for  var¬ 
ious  reasons.  Most  traditional  testing  tech¬ 
niques  cannot  be  directly  applied  to  ser¬ 
vices  in  the  SOA  world  because  testing  has 
to  occur  at  runtime  and  in  real  time  [8], 
Independent  testing  of  a  service  from  a 
service  provider  perspective  is  different 
from  that  of  a  service  consumer. 
Moreover,  the  service  provider  and  con- 


“Modeling  and 
simulation  can  provide 
some  guidance  and 
confidence  during  the 
design  phase ,  but  they 
are  not  a  substitution  for 
end-to-end  testing  of 
service-based 
applications.” 

sumer  must  collaborate  and  cooperate  to 
ensure  correctness  and  trustworthiness  of 
services  [8]. 

Service  consumers  can  only  be  fully 
tested  when  the  invoked  services  (or  test 
instances  of  them)  are  available.  The  ease 
of  testing  will  most  likely  depend  on 
whether  the  service  is  internal  or  external 
to  the  organization  —  there  is  more  control 
if  it  is  internal. 

In  an  SOA  environment  it  is  common 
for  different  services  to  be  owned  by  dif¬ 
ferent  organizations  and  for  services  to 
use  different  technologies.  Because  an 
SOA  environment  is  distributed,  loosely 
coupled,  and  asynchronous,  testing  can 
be  significantly  more  complex  than  sim¬ 
ply  testing  a  set  of  known  paths  in  a  sin¬ 
gle  system  [9],  Modeling  and  simulation 
can  provide  some  guidance  and  confi¬ 
dence  during  the  design  phase,  but  they 
are  not  a  substitution  for  end-to-end  test¬ 
ing  of  service-based  applications  [9]. 
Service  consumers  will  necessarily  have 
to  be  prepared  to  deal  (or  not  to  deal) 
with  degraded  service  modes  and  com¬ 
plete  service  failure. 


Services  can  be  reused  across  applica¬ 
tions  that  cross  enterprise  boundaries. 
Changes  requested  by  one  service  con¬ 
sumer  in  an  existing  service  can  result  in 
undesired  results  for  another  service  con¬ 
sumer.  Changes  in  service  interface  and 
implementation  must  be  tested  continu¬ 
ously  by  each  of  the  service  consumers  in 
order  to  ensure  that  the  actual  service 
behavior  conforms  to  intended  behavior. 
Finally,  service  providers  have  to  exten¬ 
sively  test  their  services  because  they  can¬ 
not  anticipate  all  the  possible  scenarios  in 
which  their  service  will  be  used.  Testing 
has  to  cover  functionality,  load  testing  and 
stress  testing,  as  well  as  other  elements 
specified  in  an  SLA. 

Conclusions 

We  believe  SOA  may  be  the  best  current 
approach  for  achieving  critical  interoper¬ 
ability,  agility,  and  reusability  goals  that  are 
common  to  many  organizations. 
However,  we  also  believe  that  the  difficult 
reality  of  building  and  managing  large- 
scale  SOA-based  systems  often  gets  lost  in 
the  understandable  corporate  desire  for 
sweeping  improvements  and  the  hype  of 
vendors. 

Our  intent  is  not  to  discourage  organi¬ 
zations  from  adopting  SOA,  but  to  cau¬ 
tion  them  about  some  important  issues 
and  risks  to  consider  while  creating  their 
SOA  strategy.  Most  of  these  issues  are 
currently  active  areas  of  research  in  the 
service-oriented  computing  community. 
The  solutions  will  require  time  to 
mature.  ♦ 
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